Напомним, что сервис DRS Dump Insight - это портал самообслуживания, куда пользователи могут загружать файлы дампов DRS. После этого будет выведена информация об операциях по перемещению виртуальных машин, которые рекомендует выполнить механизм балансировки нагрузки DRS:
Плагин DRS Dump Insight в вашем vCSA позволит ответить на следующие вопросы:
Где взять список всех рекомендаций DRS?
Почему DRS выдал конкретную рекомендацию (улучшить баланс по CPU, по памяти и т.п.)?
Почему DRS не вырабатывает рекомендации по балансировке кластера?
Как созданное пользователем правило affinity/anti-affinity влияет на балансировку ресурсов в кластере?
Если применить некоторую политику в кластере, как изменится балансировка ресурсов DRS?
При установке DRS Dump Insight H5 Plugin нужно выполнить следующие действия:
Проверить версию vCenter Server Appliance - подходит только 6.5 и 6.7.
Положить пакет с плагином в папку /usr/lib/vmware-vsphere-ui/plugin-packages/ на сервере vCSA.
Добавить настройку CompressDrmdumpFiles со значением "0" в advanced options кластера.
Перезапустить службу графического интерфейса vsphere-ui командами:
service-control --stop vsphere-ui
service-control --start vsphere-ui
После установки на вкладке Monitor для каждого кластера вы увидите раздел "DRS Dump Insight".
Загрузить DRS Dump Insight H5 Plugin можно по этой ссылке (в комбо-боксе выберите версию для своего vCenter).
Летом этого года компания VMware выпустила технологические превью настольных платформ виртуализации Workstation 2018 и Fusion 2018, а на днях состоялся их финальный релиз. VMware выпустила новые версии VMware Workstation 15 и VMware Fusion 11. Давайте посмотрим, что нового появилось в платформе VMware Workstation 15, которая уже доступна для загрузки...
На днях в Лас-Вегасе началась конференция VMworld 2018 - главное в году событие в сфере виртуализации. Компания VMware уже в первый день представила немало анонсов новых продуктов и решений, но одним из главных стало объявление о выпуске обновления серверной платформы виртуализации VMware vSphere 6.7 Update 1.
На картинке выше приведены 5 основных новых возможностей vSphere 6.7 U1, давайте посмотрим на них поближе:
1. Полнофункциональный VMware vSphere Client на базе HTML5.
Наконец-то свершилось - VMware выпустила полную версию vSphere Client на базе технологии HTML5, которая заменяет собой устаревший vSphere Web Client. Теперь все операции можно будет делать через один удобный и быстрый клиент. Напомним, что VMware очень долго к этому шла, постоянно откладывала релиз полной версии, но в итоге пользователи получат единый инструмент управления виртуальной инфраструктурой.
Теперь клиент на HTML5 включает в себя не только все старые рабочие процессы, но и новые возможности, такие как упрощенная настройка механизма отказоустойчивости vCenter HA (VCHA) и функции обновлений vSphere Update Manager (VUM). Теперь нет нескольких рабочих процессов, делающих то же самое (раньше были Basic и Advanced), а также улучшились функции работы с Content Library, появился расширенный поиск, упростилась настройка запланированных задач и появились графики top-N (топы по использованию ресурсов).
2. Утилита vCenter Server Converge Tool.
Эта новая утилита позволяет смигрировать внешний сервер Platform Services Controller (PSC) на простой в управлении embedded PSC. Проблема заключалась в том, что ранее пользователи использовали внешний PSC, поскольку он поддерживал Enhanced Linked Mode (ELM). И несмотря на то, что внедренный PSC стал поддерживать ELM еще в vSphere 6.7 и vSphere 6.5 Update 2, многие пользователи еще с предыдущих версий поддерживают комплексную инфраструктуру внешних PSC с репликацией между площадками.
Сейчас все стало проще - утилита vCenter Server Converge Tool устанавливаетembedded PSC на vCenter Server Appliance (vCSA), после чего налаживает канал репликации с оставшимися внешними PSC. После того, как эта процедура пройдет на всех площадках, вы сможете отключить внешние PSC, а встроенный механизм vCenter HA сам настроится на работу с внедренными PSC.
Теперь вам не нужны сложные HA-топологии PSC с балансировщиками на разных площадках, серверы vCSA с внедренными PSC на них можно просто соединить между собой.
Утилита vCenter Server Converge Tool работает из командной строки (команда vcsa-converge-cli) и поставляется в комплекте с установщиком vCSA. Ее можно запускать в ОС Windows, macOS и Linux, а конфигурируется она через файл в формате JSON:
Еще одна задача, которая была решена - vCenter Server с компонентом embedded PSC теперь можно перенаправить на другой домен vSphere SSO (это позволяет более гибко распределять и разделять домены SSO в корпоративной инфраструктуре). Ранее это было сделано только для внешних SSO, а теперь доступно и для vCSA.
3. Новая версия vSAN и улучшения HCI.
В новой версии vSAN появилась функция Cluster Quickstart, которая позволяет инициализировать кластер, добавить в него хосты и накатить идентичную конфигурацию на них. Она включает в себя настройку механизмов HA и DRS, Enhanced vMotion Compatibility (EVC), датасторов vSAN и сетевого взаимодействия, включая Virtual Distributed Switch (VDS).
Этот воркфлоу можно использовать и для добавления новых хост-серверов ESXi в кластер, а также для его валидации (проверка корректности и идентичности настроек на всех хостах с оповещением о найденных несоответствиях).
Также появилась интеграция микрокода контроллера ввода-вывода с vSphere Update Manager (VUM), который использует утилиту обновления драйверов от вендора сервера. Таким образом, обновление драйвера I/O-адаптера можно включить в цикл обновления хоста и не заниматься этим отдельно.
Если VUM не нашел утилиты обновления от вендора, он предлагает загрузить ее (можно использовать как дефолтный, так и свой репозиторий):
4. Улучшения Content Library.
Теперь OVA-шаблоны можно импортировать из HTTPS-источника или с локального хранилища. Также содержимое OVA-пакетов можно синхронизировать между несколькими серверами vCSA (сами шаблоны синхронизировать пока нельзя). Content Library обрабатывает сертификаты и файлы манифеста, входящие в OVA-пакеты в соответствии с лучшими практиками безопасности.
Content Library также нативно поддерживает формат шаблонов VMTX и ассоциирует с ними операции, такие как развертывание ВМ напрямую из Content Library.
5. vMotion для карточек NVIDIA Quadro vDWS и поддержка Intel FPGA.
Теперь технология NVIDIA Quadro vDWS (ранее она называлась GRID) для vGPU поддерживается со стороны vSphere 6.7 Update 1. Напомним, что ранее была введена поддержка операций Suspend/Resume для GRID, а теперь появилась и поддержка горячей миграции vMotion для машин с привязкой к карточкам NVIDIA Quadro vDWS. Это позволит обновлять хосты с тяжелыми операциями (например, десктопы с CAD-приложениями) без прерывания работы пользователей.
Также VMware объявила о поддержке карточек Intel Programmable Acceleration Card с технологией Intel Arria 10 GX FPGA. Эта технология позволяет получить прямой доступ к оборудованию с помощью механизма VMware DirectPath I/O через Intel Acceleration Stack для процессоров Intel Xeon CPU с FPGA.
Также в рамках VMworld 2018 было анонсировано новое издание - vSphere Platinum, которое предоставляет расширенные функции обеспечения безопасности для корпоративной инфраструктуры. О нем мы расскажем в следующей статье.
О дате доступности для загрузки обновления VMware vSphere 6.7 Update 1 пока не сообщается.
По умолчанию тонкий клиент vSphere 6.7 Web Client показывает текущие задачи и алармы в виртуальной инфраструктуре от текущего пользователя, а чтобы увидеть эти события от других пользователей, надо сделать рефреш Web Client. Но, оказывается, есть возможность установить Live Refresh для веб-клиента таким образом, чтобы он обновлял сам последние задачи и алармы.
Делается это так:
1. Открываем на сервере vCenter файл со свойствами веб-клиента:
Для vCenter for Windows - это C:\ProgramData\VMware\vCenterServer\cfg\vsphereclient\webclient.properties
Для vCenter Server Appliance (vCSA) - это /etc/vmware/vsphere-client/webclient.properties
2. Добавляем в этот файл строчку конфигурации live.updates.enabled=true
3. Выходим из vSphere Web Client и логинимся по ссылке https://hostname:9443/vsphere-client/. Если вы залогинитесь по ссылке https://hostname/vsphere-client/, вы не увидите последние задачи и алармы других юзеров.
Эта возможность доступна, начиная с VMware vSphere 6.0 Update 1. Надо отметить, что для vCSA версии 6.5 и выше эта опция включена по умолчанию.
P.S. Кстати, в этом же файле вы можете добавить строчку tasks.refresh.rate = 60 для уменьшения частоты обновления панели задач (значение в секундах), либо можете выставить 10 (минимально) для частого обновления. Но часто обновлять задачи в окружениях с большим числом пользователей не рекомендуется, так как там могут возникнуть проблемы с производительностью веб-клиента.
Компания VMware сделала доступным список часто задаваемых вопросов по обновлению до последних версий платформ виртуализации - VMware vSphere Upgrade FAQ. В данных вопросах рассматривается как процесс обновления, так и дальнейшее функционирование инфраструктуры VMware vSphere 6.5 и 6.7.
Список вопросов по апгрейду на vSphere 6.7 и 6.5 затрагивает следующие темы:
Deployment Topologies
Migration
General Upgrade
Management Clients
Licensing
Interoperable Solutions
Networking
Storage
vCenter Server Appliance (VCSA)
Тем, кто планирует обновление, конечно же, рекомендуется эту страничку почитать. Кстати, помните, что апгрейд с недавно вышедшей версии VMware vSphere 6.5 Update 2 на VMware vSphere 6.7 пока еще не поддерживается.
Не так давно мы писали о том, что вышло обновление клиента VMware ESXi Embedded Host Client, позволяющего управлять хост-сервером ESXi через удобный веб-интерфейс. Сегодня мы поговорим о настройке клиента NTP на хосте, который необходим, чтобы виртуальные машины синхронизировали свое время с хостом через VMware Tools. Тулзы синхронизируют свое время при старте машин, операциях по созданию снапшотов (а значит и при создании бэкапов), vMotion и некоторых других событиях.
Если на хосте установлено неправильное время, то это может привести к проблемам при логине, а также невозможности старта службы vpxd на сервере vCenter Server Appliance (vCSA).
Давайте запустим ESXi Host Client по ссылке:
https://<esxi_ip_or_hostname>/UI
Далее нужно пойти в Manage > System > Time and Date, где нажать Edit settings:
Появится диалог настройки синхронизации времени хоста средствами службы NTP (ESXi NTP Client).
В поле NTP Servers нужно указать адрес сервера времени, а в поле NTP service startup policy есть 3 варианта:
Start and stop with port usage - если выставлена эта опция, то службы NTP будут запускаться автоматически при доступности порта NTP (UDP Port 123) и отключаться, если он недоступен (например, применен Security Profile для сетевого экрана, который выключает доступ по этому порту). VMware рекомендует использовать эту настройку по умолчанию.
Start and stop with host - включает и отключает службы NTP при загрузке хоста ESXi или перед его выключением.
Start and stop manually - ручное управление службами NTP с точки зрения старта и остановки.
После того, как вы настроили политику NTP-клиента, он сам еще не запустится - его нужно запустить вручную из меню Actions:
Если же вы используете для настройки времени на хосте ESXi клиент vSphere Web Client, то они находятся в разделе Configure > System > Time configuration для выбранного хоста ESXi:
Многие из вас знают, что на днях компания VMware выпустила обновление виртуального модуля для управления виртуальной инфраструктурой - VMware vCenter Server Appliance 6.7a. В основном, в этом обновлении были исправлены ошибки, связанные с апгрейдом на новую версию vSphere 6.7 с прошлых 6.5 и 6.0. Также иногда зависал vSphere Web Client при логине, и эта проблема была тоже исправлена.
Но самое интересное, что и в новой версии vCSA 6.7a тоже есть небольшая проблема апгрейда уже с версии 6.7:) Стандартно процедура обновления виртуального модуля vCenter выглядит так:
1. Через интерфейс CLI.
Добавляем образ VMware-vCenter-Server-Appliance-6.7.0.11000-8546234-patch-FP.iso к серверу vCenter Server Appliance как CD/DVD drive.
Идем на vCSA по SSH как root и выполняем команды:
Для стейджинга ISO: software-packages stage –iso
Для просмотра контента на стейджинге: software-packages list –staged
Для установки rpm-пакетов со стейджинга: software-packages install –staged
2. Через интерфейс VAMI.
Добавляем образ VMware-vCenter-Server-Appliance-6.7.0.11000-8546234-patch-FP.iso к серверу vCenter Server Appliance как CD/DVD drive.
Логинимся в интерфейс VAMI по адресу https://fqdn-of-vcenter:5480
Нажимаем Update и в правом верхнем углу выбираем Check Updates -> Check CD Rom.
Нажимаем Update, затем Stage и Install.
Также это обновление можно сделать по URL новой версии, которая дефолтно должна находиться в рамках процедуры описанной выше, только без присоединения ISO-образа к vCSA. Но сейчас в этом апдейте какие-то проблемы с этим, поэтому когда нажмете кнопку Update в VAMI, то затем надо нажать Settings и добавить туда следующий URL:
На днях компания VMware сделала доступной новую версию HTML5-клиента для управления виртуальной инфраструктурой VMware vSphere 6.7. Это первый релиз, который вышел с момента включения нового клиента в состав последней версии vSphere 6.7 (напомним, что об этом мы писали тут и тут). Ну а о прошлой версии vSphere Client 3.36, доступной ранее на VMware Labs, мы писали вот тут.
Давайте посмотрим, что нового появилось в версиях vSphere Client 3.37 и 3.38:
Пользовательские маппинги гостевых ОС для виртуальных машин.
Поддержка последовательных портов для ВМ.
Улучшенный поиск, включая:
Редизайн страниц результатов
Возможность фильтрации результатов поиска по таким полям, как power state, guest os, host, clusters, datacenter
Возможность сохранить поиск.
Улучшения быстрых операций с питанием ВМ.
Просмотр опций объекта vApp для виртуальных машин в режиме только для чтения.
Возможности сетевых функций SRIOV в мастере клонирования на вкладке Hardware.
Ресайзинг мастера миграции до любых размеров за счет функций фреймворка VMware Clarity.
Скачать обновленный VMware vSphere Client 3.38 можно по этой ссылке.
Ну а сегодня расскажем о новых возможностях программных интерфейсов API в vSphere 6.7. В первую очередь надо сказать, что появилось несколько наборов RESTful API, которые были полностью переписаны, чтобы соответствовать современному состоянию виртуальной инфраструктуры vSphere.
1. API виртуальных модулей (Appliance API).
Здесь основные улучшения произошли в сфере резервного копирования и восстановления модулей, а также их обновления. Помимо этого, был улучшен процесс мониторинга процесса бэкапа, и, что главное, появилась возможность запланированного запуска резервного копирования через API:
Кроме этого, теперь есть возможность управления жизненным циклом модуля и его обновлением через API. Здесь доступен полный набор интерфейсов - от предпроверок для проведения обновления, до стэйджинга и накатывания самого апдейта с последующей валидацией.
Многие API виртуальных модулей, которые ранее были доступны как превью, теперь выпущены официально. Среди них: управление службами модуля, изменение сетевой конфигурации и настроек NTP. Также появилась давно ожидаемая фича - питанием виртуального модуля теперь можно управлять через API.
2. Обновления vCenter API.
В интерфейсе vCenter RESTful API появилось более 40 новых методов. Они касаются взаимодействия с гостевыми ОС виртуальных машин, просмотра политик хранилищ Storage Policy Based Management (SPBM), а также управления службами vCenter.
Кроме того, через API теперь доступны операции по управлению жизненным циклом vCenter - развертывание, реконфигурация развернутой топологии, отчет о текущем состоянии Platform Services Controller (PSC) и т.п.
Также появилась возможность и обновлять vCenter через API:
3. Прочие улучшения API.
Помимо перечисленного, были сделаны улучшения в vSphere Web Services (SOAP) API. Появились методы по очистке всех сработавших алармов, функциональность управления виртуальным Trusted Platform Module (TPM), а также механизмом Enhanced vMotion Compatibility (EVC).
Также, как мы писали вот тут, появился новый метод по созданию мгновенного клона ВМ (Instant Clone):
Ну и, наконец, появилась возможность узнать дату и время создания виртуальной машины. Для этого нужно обратиться к свойству createDate объекта VirtualMachineConfigInfo.
Как все уже знают, недавно компания VMware выпустила обновленную версию платформы виртуализации VMware vSphere 6.7. Напомним наши статьи о нововведениях этого решения:
Ну а сегодня мы расскажем еще об одной возможности vSphere в плане безопасности - поддержке технологии Virtualization Based Security (VBS) операционных систем Microsoft. Механизм VBS позволяет превратить сервер или рабочую станцию на базе ОС Windows Server 2016 или Windows 10 в защищенные системы, исполняющиеся в рамках гипервизора Windows, при этом некоторые компоненты выносятся за пределы гостевой системы. Например, за рамки ОС выносится система управления хэшированными парами логин/пароль (креденшены), называющаяся Credential Guard.
Как мы видим на картинке, гипервизор обеспечивает виртуализацию гостевой системы на сервере или ноутбуке, а также канал обмена между внешними компонентами (Credential Guard, Device Guard) и ОС. Такая архитектура обеспечивает большие трудности при доступе злоумышленников к областям памяти, где хранятся хэши паролей различных пользователей - ведь эта область вынесена за пределы операционной системы.
Также аппаратное обеспечение компьютера должно иметь в своем составе модуль TPM 2.0 (Trusted Platform Module), который обеспечивает механику безопасной загрузки (Secure Boot). Ведь если не использовать механизм безопасной загрузки, то атаку можно провести на сам гипервизор, подменив его компоненты, а дальше уже иметь доступ к основной виртуальной машине и остальным компонентам гипервизора, в том числе хранилищу паролей. Таким образом, для полной защиты нужно использовать связку VBS+TPM 2.0 (вторая версия TPM поставляется уже со всем современным оборудованием).
Чтобы такая схема работала, нужно обеспечить выполнение следующих требований:
UEFI firmware (не BIOS).
Опция безопасной загрузки Secure Boot с поддержкой TPM.
Поддержка технологии Hardware virtualization (опция процессоров Intel VT/AMD-V) и функций IOMMU.
И самое главное - ОС Windows должна быть установлена со всеми этими включенными опциями, иначе потом настраивать VBS будет проблематично.
В случае с гипервизором ESXi для незащищенной виртуальной машины Windows все выглядит вот таким образом:
Чтобы защитить машину с помощью VBS, потребуется использовать вложенную (nested) виртуализацию - ведь гипервизор Windows Hypervisor надо запустить на платформе VMware ESXi. Для этого в настройках виртуальной машины надо выставить опцию Enable для пункта Virtualization Based Security:
Это позволит открыть все необходимые опции процессора для гостевой ОС виртуальной машины, в которой также будет работать гипервизор.
Выглядеть это будет следующим образом:
Чтобы эта схема работала, нужно выполнить 2 условия:
Виртуальная машина должна иметь виртуальное железо Virtual Hardware версии 14, которое появилось в vSphere 6.7.
Гостевую ОС виртуальной машины надо развертывать на базе UEFI и с уже включенной опцией Secure Boot (обратите внимание на эту опцию на панели Boot Options в разделе VM Options (см. скриншот настроек выше).
Ну и последняя деталь - это модуль TPM. Для физических систем этот модуль делается с расчетом на одну систему, имеет небольшой объем памяти защищенного хранилища (измеряется в килобайтах) и работает весьма медленно, так как это serial device.
Поэтому VMware сделала виртуальное устройство - vTPM 2.0, которое в качестве хранилища использует обычный файл .nvram. Физический TPM не рассчитан на то, чтобы поддерживать сотни виртуальных машин на одном сервере (просто не хватит объема хранилища и быстродействия), а виртуальный vTPM отлично справляется с этой задачей. К тому же, виртуальную машину с виртуальным vTPM можно переносить между серверами с помощью vMotion и делать ее резервные копии.
Но, само собой, файл nvram надо хорошо зашифровать, поэтому для виртуальной машины нужно включить VM Encryption. Это обеспечит работоспособность машины в защищенной среде совместно с опцией VBS. При этом диски ВМ шифрованными не будут, что позволит получить доступ к данным на уровне VMDK дисков в случае утери ключей.
Самое интересное, что vTPM 2.0 не требуется как-то отдельно устанавливать и настраивать - он автоматически обнаруживается средствами Windows со стандартными драйверами:
Утилита Device Guard and Credential Guard hardware readiness tool от компании Microsoft определяет этот vTPM, как совместимый, поэтому можете использовать его для виртуальных машин, к которым предъявляются повышенные требования к безопасности.
Недавно мы писали о новых возможностях HTML5-клиента для VMware vSphere 6.7. Он уже содержит в себе интерфейсы VMware vSAN и Update Manager, что делает его уже почти готовым к полноценной эксплуатации в производственной среде.
Но помимо vSphere Client, в инфраструктуре vSphere есть и ESXi Host Client, который позволяет управлять отдельными хост-серверами ESXi через веб-интерфейс.
Посмотрите полезный обзор новых фичей ESXi Host Client 6.7 от Virtualization24x7:
Как вы знаете, за прошедшие несколько недель состоялось несколько больших релизов от VMware, вышли обновления как самой платформы виртуализации VMware vSphere 6.7, так и апдейты продуктов VMware Site Recovery Manager 8.1, vRealize Operations 6.7 и других.
Вот суммарно что нового появилось в vSphere 6.7, если постараться уместить это на одну картинку:
Поэтому для многих пользователей VMware vSphere 6.5/6.0/5.5 пришло время большого апгрейда, особенно учитывая, что 19 сентября этого года заканчивается поддержка vSphere 5.5.
Правда не надо забывать, что системы резервного копирования еще не поддерживают vSphere 6.7, но, я думаю, эта ситуация исправится в самом ближайшем будущем. Ну и помните, что напрямую обновиться с vSphere 5.5 на 6.7 не получится, придется делать промежуточный апгрейд на 6.0/6.7:
Поддерживаемые пути апгрейда на vSphere 6.7 включают в себя следующие способы:
Установщик ESXi
Интерфейс ESXCLI
Решение vSphere Update Manager (VUM)
Механизм Auto Deploy
VMware написала в своем блоге интересный пост с рекомендациями по обновлению на vSphere 6.7, приведем оттуда самые важные моменты.
1. Общие рекомендации по платформе vSphere.
vSphere 6.0 - это минимальная версия для апгрейда на vSphere 6.7.
vSphere 6.7 - это последний релиз, который требует ручного указания всех сайтов SSO.
В vSphere 6.7 только TLS 1.2 включен по умолчанию, TLS 1.0 и TLS 1.1 по умолчанию отключены.
Так как структура метаданных томов VMFS6 изменилась, чтобы поддерживать выравнивание по 4K блокам, вы не сможете сделать апгрейд датастора VMFS5 на VMFS6. Это так и осталось со времени vSphere 6.5 (смотрите KB 2147824).
2. Рекомендации по обновлению vCenter.
Развертывание vCenter Server Appliance 6.7 (vCSA) является рекомендуемой конфигурацией.
vCenter Server 6.7 for Windows - это последний релиз для платформы Windows, далее все будет только на базе виртуального модуля.
vCenter Server 6.7 не поддерживает Host profiles с версией ниже 6.0 (см. KB52932).
vCenter Server 6.7 поддерживает работу Enhanced Linked Mode с внедренным компонентом Embedded PSC. Но это поддерживается только для чистых установок, а не апгрейдов. Будьте внимательны!
Если вы используете защиту сервера vCenter в платформе vSphere 6.5 (vCenter High Availability, VCHA), то нужно будет удалить всю конфигурацию VCHA перед проведением апгрейда.
3. Совместимость с другими продуктами VMware.
На момент написания статьи vSphere 6.7 не поддерживала работу со следующими решениями последних версий:
VMware Horizon
VMware NSX
VMware Integrated OpenStack (VIO)
VMware vSphere Integrated Containers (VIC)
Также отметим, что в этой версии vSphere больше нет продукта VMware vSphere Data Protection (VDP), об этом мы писали здесь. Также нотификацию об этом можно увидить на странице сайта VMware, посвященной VDP.
4. Рекомендации по оборудованию.
vSphere 6.7 больше не поддерживает некоторые модели процессоров от AMD и Intel. Их список приведен вот тут, а проверить текущую совместимость можно по этой ссылке.
Следующие CPU пока еще поддерживаются, но их поддержка может быть прекращена в следующей версии:
Intel Xeon E3-1200 (SNB-DT)
Intel Xeon E7-2800/4800/8800 (WSM-EX)
Виртуальные машины, которые совместимы с ESX 3.x и всеми более поздними версиями (начиная с hardware version 4) поддерживаются хостами ESXi 6.7.
Версия железа Hardware version 3 больше не поддерживается.
VM hardware version теперь называется VM Compatibility. Помните, что сначала надо обновить ее на машине до последней версии перед использованием на платформе vSphere 6.7.
Ну а мы со своей стороны рекомендуем всегда делать свежую установку vSphere, если это возможно, а не делать апгрейд, чтобы накопившиеся в прошлом прошлом проблемы вы не унаследовали в новой инсталляции.
Как вы все уже знаете, недавно компания VMware выпустила обновленную версию платформы виртуализации VMware vSphere 6.7. Помимо описания новых возможностей решения мы также останавливались на новых функциях VMware vCenrer 6.7, а сегодня расскажем о некоторых нововведениях тонкого клиента VMware vSphere Client 6.7, построенного на базе технологии HTML5.
Напомним, что vSphere Client не удалось добить до полной функциональности, поэтому VMware выпустила и финальный релиз vSphere Web Client 6.7 на базе технологии Flash. Но обещают, что функционал клиентов уже почти одинаковый. Одним из шагов на пути к этому стала поддержка основных рабочих процессов vSphere Update Manager (VUM) в HTML5-клиенте.
Надо начать с того, что интерфейс VUM был полностью переработан, а не просто скопирован с Web Client. Рабочие процессы стали проще и понятнее.
Кстати, обратите внимание на гифке выше, как удобно теперь стало искать обновления для хостов ESXi с помощью встроенного в таблицу со списком апдейтов поля поиска.
Многошаговый мастер по обновлению хостов ESXi 6.0-6.7 был заменен простым рабочим процессом, в рамках которого процедура remediation требует лишь нескольких кликов:
Также процедура предварительной проверки кластера (pre-check) была вынесена в отдельный рабочий процесс, чтобы не инициировать воркфлоу обновления напрасно.
Между тем, не все рабочие процессы VUM были реализованы - в новой версии этого средства нет обновления VMware Tools и средств проверки совместимости "железа" (hardware compatibility). Но их обещают включить в ближайшем релизе.
Также существенно был ускорен процесс обновления с vSphere 6.5 на vSphere 6.7. Если раньше перед проведением обновления нужно было перезагрузить ESXi, а потом еще и после во второй раз, то теперь само обновление за счет оптимизаций идет быстрее, а перезагрузка требуется всего одна.
Помимо этого, теперь информация об обновлениях более полная и включает в себя критичность апдейта, требуется ли перезагрузка, что именно находится внутри и т.п.
Как вы знаете, на прошлой неделе компания VMware выпустила обновление платформы виртуализации VMware vSphere 6.7. Одновременно с этим было выпущено и обновление средства создания отказоустойчивых кластеров VMware vSAN 6.7 (оно идет в комплекте с vSphere). Напомним, что о прошлой версии vSAN 6.6.1 мы писали вот тут.
Давайте посмотрим, что нового появилось в vSAN 6.7:
1. Новый интерфейс vSphere Client.
Теперь vSAN можно управлять через HTML5-клиент vSphere Client, который построен на базе фреймворка Clarity, что делает использование рабочих процессов для кластеров хранилищ простым и понятным. Надо отметить, что эти рабочие процессы не были перенесены напрямую из Web Client, а разработаны с самого начала, поэтому выглядят современно и просты в использовании.
2. Поддержка vRealize Operations для vCenter и разделов vSAN.
Традиционно пользователи vSAN должны были использовать две консоли - консоль vCenter и консоль vRealize Operations. Теперь в новой версии vSphere 6.7 появилась функция "vRealize Operations within vCenter", которая позволяет просматривать информацию о кластере vSAN, его параметрах и проблемах через vSphere Client в разделе vRealize Operations:
Вся базовая аналитика кластеров vSAN видна здесь, а если вам потребуется более детальная информация для изучения проблемы - вы можете запустить соответствующий раздел vRO прямо отсюда в два клика.
3. Поддержка других кластерных решений.
В новой версии vSAN 6.7 теперь поддерживается использование других кластерных технологий в рамках датасторов vSAN:
Среди поддерживаемых кластерных решений для vSAN уже были следующие продукты: Microsoft SQL Always-on Availability Groups (AAG), Microsoft Exchange Database Availability Groups (DAG) и Oracle Real Application Clusters (RAC). Таргеты для этих решений предоставляются средствами технологии vSAN iSCSI.
Теперь в этот набор добавилась технология Windows Server Failover Clusters (WSFC) - она также поддерживается со стороны vSAN 6.7. На эту тему VMware выпустила отдельное видео:
4. Функция Adaptive Resync.
В vSAN 6.7 появилась абсолютно новая фича Adaptive Resync, которая позволяет адаптивно регулировать ширину канала для операций ввода-вывода VM I/O и Resync I/O, в зависимости от загрузки производственной системы.
Эта возможность также позволяет гарантировать, что из-за выедания канала каким-то вида трафика, использующего его, остальные типы трафика (см. на картинке выше) не будут блокированы. Также Adaptive Resync выделяет каналам ввода вывода для ВМ и синхронизации кластера vSAN необходимые ресурсы, когда известно, что их использование не скажется на производительности в целом.
5. Оптимизированный механизм de-staging.
В vSAN 6.7 было сделано множество улучшений в плане оптимизации путей данных, а именно дестейджинга данных из кэша на запись (Write Cache) в сторону дисков. Вследствие этого все работает намного быстрее, теперь кэш на запись быстрее "дренируется" на диски, освобождая место для следующих операций ввода-вывода. Это ускоряет не только работу виртуальных машин, но и каналов ресинхронизации.
6. Улучшенные проверки состояний (хэлсчеки).
В vSAN самодиагностика поднялась на новый уровень. Теперь данные о конфигурации кластера собираются с помощью vSAN Support Insight и визуализуются в vSphere Client.
vSAN 6.7 теперь предоставляет следующие новые хэлсчеки, которые будут полезны для администраторов и служб технической поддержки:
Верификация перехода в режим Maintenance mode (позволяет убедиться в правильности вывода хоста из эксплуатации на время или навсегда).
Проверка консистентности конфигураций для раздела advanced settings.
Улучшенные тесты сетевой доступности для сетей vSAN и vMotion.
Улучшенная проверка установки vSAN Health service.
Теперь улучшенные проверки физических дисков можно комбинировать с другими несколькими проверками в рамках единой нотификации.
Проверка Firmware теперь независима от проверки драйверов.
Скачать VMware vSAN 6.7 можно теперь в составе платформы VMware vSphere 6.7. Ну и, напоследок, технический обзор решения VMware vSAN 6.7:
Как вы знаете, совсем недавно компания VMware выпустила обновление платформы виртуализации VMware vSphere 6.7, включая гипервизор ESXi 6.7 и средство управления vCenter Server 6.7. Одной из важных составляющих виртуальной инфраструктуры виртуализации является инфраструктура резервного копирования виртуальных машин. Вряд ли можно себе представить крупную компанию, которая обновляет хосты ESXi 6.0/6.5 на 6.7 и готова остаться без резервного копирования ВМ.
Между тем, с поддержкой новой версии vSphere 6.7, которая вышла 18 апреля, у вендоров решений резервного копирования все весьма плохо. Давайте посмотрим, как именно (об этом рассказал блог tinkertry):
Как мы видим, только Veeam позаботилась о том, чтобы проинформировать своих пользователей о поддержке (а точнее неподдержке) новой версии vSphere 6.7.
При попытке использовать Veeam Backup and Replication 9.5 Update 3 вы получите вот такое сообщение об ошибке:
Error: Object reference not set to an instance of an object
Поэтому придется ждать обновления Update 3a, в котором vSphere 6.7 будет полностью поддерживаться для резервного копирования, репликации и восстановления виртуальных машин. Оно выйдет в самом ближайшем будущем (мы обновим пост).
На днях компания VMware объявила о выпуске обновленной версии платформы виртуализации VMware vSphere 6.7 (она уже доступна для скачивания). Сегодня мы расскажем о новой версии управляющего сервера VMware vCenter 6.7 и его новых возможностях.
Начать надо с того, что виртуальный модуль VMware vCenter Server Appliance (vCSA) 6.7 теперь рекомендован для развертывания по умолчанию, а значит VMware уже окончательно рекомендует перейти на этот вариант средства управления виртуальной инфраструктурой.
1. Средства управления жизненным циклом.
Об этом мы уже упоминали в статье про vSphere 6.7. Теперь vCenter Server Appliance 6.7 позволяет развернуть vCenter Server с внедренным компонентом Embedded PSC и поддержкой Enhanced Linked Mode. Это дает следующие преимущества:
Теперь для высокой доступности vCSA не нужен балансировщик, и технология vCenter Server High Availability поддерживается нативно.
Теперь проще развертывать инфраструктуру Single Sign-On Domain.
Поддержка максимумов масштабирования vSphere.
Можно делать до 15 развертываний vCSA в рамках одного домена vSphere SSO.
Уменьшение числа узлов, которые надо обслуживать и поддерживать.
Также в составе vSphere 6.7 есть последняя версия vCenter Server 6.7 for Windows, которая уже не будет доступна в следующих версиях платформы. Теперь при миграции старого vCenter на vCSA есть две опции по импорту исторических данных БД:
Развертывание и мгновенный импорт данных
Развертывание и импорт данных в фоновом режиме
При этом показывается примерное время простоя сервисов vCenter во время этих процессов:
Также если вы выбрали импорт данных в бэкграунде, то потом можете поставить этот процесс на паузу. Помимо этого, был улучшен интерфейс процесса миграции, а также появилась возможность выбрать кастомные порты, чтобы не перенастраивать фаервол.
Что касается апгрейда с прошлых версий, то vCenter поддерживает только обновление с vSphere 6.0 и 6.5, а vSphere 5.5 остался в пролете, хотя все еще много пользователей этой версии. Таким клиентам надо будет делать чистую установку или мигрировать сначала на 6.0/6.5 (лучше, все же, ставить заново).
Кстати, помните, что конец поддержки vSphere 5.5 наступает 19 сентября 2018 года.
2. Мониторинг и управление.
В первую очередь надо сказать, что интерфейс инструментария vSphere Appliance Management Interface (VAMI) теперь построен на базе фреймворка Clarity, что делает работу с vCSA простой и приятной:
Теперь при управлении vCSA можно пользоваться отдельным разделом Monitoring для проверки состояния виртуального модуля, а также появилась вкладка Disks, где видны разделы vCSA и их заполненность.
Также появилась вкладка Services, где можно смотреть за состоянием служб vCSA. Кроме этого, были улучшены службы Syslog (теперь можно использовать до трех таргетов), а также Update (теперь можно выбрать патч или апдейт, который будет накатываться). Из VAMI теперь можно отправить патч на стейджинг и потом поставить его, ранее это было доступно только через CLI.
Помимо этого, теперь информация об обновлениях более полная и включает в себя критичность апдейта, требуется ли перезагрузка, что именно внутри и т.п.
Ну и одна из главных ожидаемых возможностей - бэкап сервера vCSA на уровне файлов. Теперь можно задать расписание резервного копирования и сколько резервных копий сохранять:
Помимо бэкапа есть и восстановление, конечно. При этом браузер архивных копий показывает их все, без необходимости искать пути до этих бэкапов.
3. Улучшения vSphere Client.
Теперь в HTML5-клиенте vSphere Client появились обновленные рабочие процессы для следующей функциональности:
vSphere Update Manager
Content Library
vSAN
Storage Policies
Host Profiles
vDS Topology Diagram
Licensing
Но, поскольку vSphere Client не удалось добить до полной функциональности, VMware выпустила и финальный релиз vSphere Web Client 6.7 на базе технологии Flash. Но обещают, что функционал уже почти одинаковый.
Из нового в vSphere Client - появились фичи Platform Services Controller (PSC) UI (/psc), которыми можно управлять через раздел Administration. Кроме этого, появилась отдельная вкладка Certificate management в разделе Configuration.
4. Утилиты CLI.
Вернулась утилита cmsso-util, которая может делать отчеты по виртуальным модулям vCSA, находящимися в рамках одного SSO-домена. Также можно сравнить 2 домена SSO и выгрузить в JSON-файл различия между этими доменами. Кроме этого, можно мигрировать лицензии, тэги, категории и права доступа из одного домена SSO в другой.
Второе улучшение CLI - это установщик vCSA, который позволяет управлять жизненным циклом этого виртуального модуля. vCenter Server Appliance ISO идет вместе с примерами JSON-шаблонов развертывания. Эти шаблоны можно использовать для унификации развертывания серверов vCenter, накатывая эти JSON в пакетном режиме друг за другом. Это позволяет убедиться в унификации конфигурации всех узлов vCenter в рамках больших инсталляций на нескольких площадках.
Скачать платформу VMware vSphere 6.7, содержащую управляющие компоненты VMware vCenter 6.7 и vCSA 6.7 можно по этой ссылке.
Компания VMware, спустя ровно полтора года с момента релиза vSphere 6.5, анонсировала скорую доступность новой версии платформы - VMware vSphere 6.7.
Этот релиз сфокусирован на четырех основных областях улучшений:
Поддержка увеличивающегося числа и разнообразия приложений.
Рост объемов использования гибридных облаков.
Понимание глобального расширения онпремизных датацентров.
Безопасность инфраструктуры и приложений.
Давайте посмотрим, что нового появилось в VMware vSphere 6.7:
1. Enhanced vCenter Server Appliance (vCSA) и масштабируемая инфраструктура.
Теперь в vCSA есть несколько новых API, которые выводят управление платформой на качественно другой уровень. Кроме того, теперь vCSA поставляется с интегрированными службами embedded platform services controller (обеспечивающими работу служб Single Sign-On), которые могут работать в режиме enhanced linked mode.
Также существенно была увеличена производительность vCSA:
В 2 раза выросло число операций vCenter в секунду.
В 3 раза уменьшилось потребление памяти.
В 3 раза увеличилось число операций DRS (например, включение виртуальной машины и ее первичное размещение в кластере).
При накате мажорных обновлений теперь требуется не 2 перезагрузки, а одна (Single Reboot).
Новый механизм vSphere Quick Boot позволяет перезагрузить гипервизор без рестарта всего хоста ESXi.
3. Доработанный HTML5 vSphere Client.
В новом релизе будет обновленная версия клиента для управления vSphere Client на базе технологии HTML5 (добавлены функции управления vSAN и Update Manager), правда пока не понятно, будет ли это полноценная замена vSphere Web Client, или обе версии пока продолжат существовать совместно.
4. Большие улучшения безопасности.
VMware vSphere 6.7 предоставляет поддержку аппаратного модуля Trusted Platform Module (TPM) 2.0, а также появился виртуальный модуль Virtual TPM 2.0. Все это позволяет защититься от атак с подменой хостов и виртуальных машин, а также предотвратить загрузку неавторизованных компонентов.
Также были сделаны улучшения механизма VM Encryption в части рабочих процессов при использовании шифрования. Теперь при миграции виртуальных машин между различными экземплярами vCenter также можно использовать Encrypted vMotion, что расширяет сферу применения данной технологии до гибридных облачных инфраструктур (защищенная горячая миграция в датацентр сервис-провайдера) или инфраструктур с географически разнесенными датацентрами.
Помимо этого, vSphere 6.7 теперь поддерживает технологию Virtualization Based Security, которая используется в гостевых ОС Microsoft Windows.
5. Улучшения поддержки высокопроизводительных приложений.
Как многие из вас знают, поддержка vGPU от NVIDIA и AMD есть в платформе vSphere уже довольно давно. Используется она сейчас не только для виртуальных ПК, но и для таких задач, как системы искусственного интеллекта, machine learning, big data и прочее. Теперь в vSphere 6.7 поддержка такого рода вариантов использования была расширена.
С помощью технологии vSphere Persistent Memory пользователи могут использовать специальные аппаратные модули от Dell-EMC и HPE, которые могут использовать высокопроизводительные системы хранения с большим числом IOPS или предоставлять их возможности гостевым системам как non-volatile memory. Теперь во многих вариантах использования высокопроизводительные приложения смогут работать быстрее.
6. Бесшовная интеграция с гибридной средой.
Теперь в VMware vSphere 6.7 появился режим работы vCenter Server Hybrid Linked Mode, в котором можно соединить две инфраструктуры - вашу онпремизную с одной версией vSphere и облачную, например, VMware Cloud on AWS с другой версией платформы.
Помимо этого, в vSphere 6.7 появились механизмы Cross-Cloud Cold и Hot Migration, которые позволяют переносить нагрузки в онлайн и офлайн режиме между облаками и онпремизной инфраструктурой.
Когда это происходит, виртуальной машине приходится перемещаться между хостами с разными наборами инструкций процессора. Поэтому в vSphere появилась технология Per-VM EVC (Enhanced vMotion Compatibility), которая позволяет подготовить виртуальную машину к миграции на совершенно другое оборудование.
Также появилась фича поддержки операций cross-vCenter, mixed-version provisioning (таких как vMotion, полное клонирование, холодная миграция), которая позволяет производить эти операции между различными vCenter различных версий (что тоже неизбежно в гибридной среде - вроде связки с vCloud on AWS).
Иногда администраторы пытаются изменить имя хоста для сервера VMware vCenter, vCenter Server Appliance (vCSA) или компонента Platform Services Controller (если он развертывается на отдельном хосте). В этом случае коллеги ищут, как это сделать и натыкаются на вот эту KB 2130599.
Действительно, сделать это никак нельзя (по крайней мере, для VC версий 6.0 и 6.5). У vCenter есть идентификатор PNID (primary network identifier), который также называется System Name во время инсталляции. Он присваивается в момент развертывания vCenter/PSC, и если вы указали FQDN-имя, то PNID им и станет, а если IP-адрес, то он тогда станет PNID.
Если вы указали FQDN-имя, то вы сможете поменять IP-адрес vCenter, и это ни на что не повлияет. Но если же вы при развертывании вбили IP-адрес как System Name, то уже не только имя, но и IP сервера vCenter/vCSA поменять вы не сможете.
Чтобы узнать, какой у вас на сервере PNID, надо выполнить такую команду:
Если же вы, все-таки, поменяете имя vCenter или vCSA, то их службы попросту не смогут запуститься, а в логе vmware-sts-idmd.log вы увидите вот такой текст:
[2015-07-16T08:17:31.353-06:00 vsphere.local 47c25a86-20c3-49c6-9ec0-c5579b36c83d ERROR] [IdentityManager] Failed to authenticate principal [Administrator@domain] for tenant [vsphere.local]
com.vmware.identity.idm.IDMLoginException: Access denied
Ну а в логе vpxd.log - вот такой:
2015-09-01T10:41:51.532-06:00 warning vpxd[03740] [Originator@6876 sub=Default] Failed to connect socket; <io_obj p:0x000000000c4d83d8, h:3392, <TCP '0.0.0.0:0'>, <TCP '</font>IP_Address'>>, e: system:10060(A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond)
2015-09-01T10:41:51.532-06:00 error vpxd[03740] [Originator@6876 sub=HttpConnectionPool-000011] [ConnectComplete] Connect failed to <cs p:0000000008d2dda0, TCP:</font>vcenter.domain.local:443>; cnx: (null), error: class Vmacore::SystemException(A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond)
Кстати, если у вас остался снапшот vCenter до смены имени хоста - можете просто к нему откатиться. Ну или можете сделать бэкап базы VC, развернуть новый сервер с новым System Name и накатить на него этот бэкап.
Продолжаем информировать вас о выпусках обновлений и заплаток уязвимостей Meltdown и Spectre для виртуальной инфраструктуры VMware vSphere. Напомним наши прошлые посты:
На днях наш читатель Стас прислал новость о том, что VMware выпустила обновления, закрывающие уязвимость Spectre, на этот раз для ключевых компонентов виртуальной инфраструктуры - серверов vCenter и ESXi. Таким образом, согласно VMware Security Advisory VMSA-2018-0004.3, теперь от уязвимости Spectre защищены все основные продукты VMware трех последних поколений:
Начнем с обновлений для vCenter. Тут были выпущены следующие апдейты:
Для серверов VMware ESXi были выпущены следующие патчи:
ESXi550-201803001 (ESXi550-201803401-BG и ESXi550-201803402-BG)
ESXi600-201803001 (ESXi600-201803401-BG и ESXi600-201803402-BG)
ESXi650-201803001 (ESXi650-201803401-BG и ESXi650-201803402-BG)
Чтобы скачать эти обновления для ESXi, нужно пойти VMware Patch Portal и поискать там обновления для соответствующей версии ESXi.
Кроме наката патчей гипервизора VMware ESXi, вам также придется обновить микрокод серверов. Более подробная информация об этом приведена в KB 52085.
Помните, что порядок наката обновлений безопасности таков:
1. Накатываем обновления vCenter.
2. Обновляем ПО гипервизора на серверах VMware ESXi - накатываем апдейты, заканчивающиеся на 01-BG (позволяет гостевым ОС использовать новый механизм speculative-execution control), одновременно с этим обновляем и микрокод серверов (апдейты, заканчивающиеся на 02-BG), которое применяется в процессе загрузки ESXi. Оба патча накатываются в рамках одного профиля.
На сайте nolabnoparty.com появилась отличная статья о том, как нужно выключать и включать кластер отказоустойчивых хранилищ VMware vSAN таким образом, чтобы не повредить данных, и включить его потом без особых проблем. Инструкция может оказаться полезной тем администраторам, которым необходимо остановить кластер vSAN целиком в целях обслуживания оборудования (серверы, коммутаторы, стойка и т.п.).
Выключение кластера vSAN
1. Для начала вам нужно выключить все виртуальные машины, кроме сервера VMware vCenter (неважно, обычный это VC или vCSA):
2. Мигрируем с помощью vMotion сервер vCenter на хост ESXi01 (тот хост, который вы считаете своим первым хостом в виртуальной инфраструктуре):
Также на первый хост ESXi настоятельно рекомендуется перевести контроллер домена Active Directory.
3. Теперь надо убедиться, что в данный момент в кластере vSAN нет процессов ресинхронизации (Resyncing Components). Для этого надо зайти в соответствующий раздел на вкладке Monitor:
На этом скриншоте видно, что никаких процессов ресинхронизации сейчас не идет. Если они у вас есть, то следует дождаться их завершения.
4. Переводим все хосты VMware ESXi (кроме ESXi01) в режим обслуживания (Maintenance Mode):
В настройках режима обслуживания уберите галку с варианта переместить машины (Move powered-off and suspended virtual machines...), а также выберите вариант не перемещать данные кластера vSAN (No data evacuation):
5. Выключите гостевую ОС виртуальной машины c VMware vCenter. Для этого в контекстном меню vCenter или vCSA выберите пункт Shut Down Guest OS:
После этого у вас, само собой, отпадет соединение с VMware vSphere Web Client:
6. Зайдите на хост ESXi через ESXi Host Client (ссылка https://<ip esxi>/ui) и переведите сервер в режим обслуживания, выбрав из контекстного меню пункт Enter maintenance mode:
Аналогично укажите, что не нужно переносить данные кластера vSAN:
Также это можно сделать следующей командой esxcli в консоли сервера:
# esxcli system maintenanceMode set -e true -m noAction
Включение кластера VMware vSAN
1. Сначала последовательно выводим хосты ESXi из режима обслуживания, начав с первого:
Сделать это также можно командой esxcli:
# esxcli system maintenanceMode set -e false
2. Включаем на хосте ESXi01 сервер vCenter и контроллер домена Active Directory:
3. Идем на вкладку Monitor и там в разделе Health убеждаемся, что все узлы в порядке и кластер vSAN прошел все проверки:
4. Только после этого включаем все виртуальные машины:
Многие из вас иногда хотят получить так называемый "Support Bundle", содержащий лог-файлы, диагностическую информацию и метрики производительности, который помогает решать проблемы в инфраструктуры VMware vSphere. В первую очередь, этот бандл нужен для предоставления службе технической поддержки VMware GSS (Global Support Services) информации о конфигурации виртуальной среды, чтобы она могла решать возникающие у клиентов проблемы в рамках обращений (тикетов) в техподдержку.
Но, кроме этого, данный бандл может пригодиться и вам, как, например, описано в этой статье для анализа причин "розового экрана смерти" и прочих аномалий.
Давайте рассмотрим основные способы получения support bundle как для серверов VMware vCenter (для Windows или виртуального модуля vCenter Server Appliance, vCSA), так и для серверов VMware ESXi. Кстати, надо учитывать, что после экспорта бандла с логами результирующий файл будет размером 30-300 МБ в зависимости от того, что вы туда включите, а также как давно и интенсивно менялась конфигурация виртуальной среды.
Получение Support Bundle для серверов vCenter
Самый простой способ получить саппорт бандл - это выгрузить его с помощью vSphere Web Client. Для этого нужно выбрать сервер vCenter в иерархии инвентори и выбрать пункт Export System Logs (работает как для обычного vCenter, так и для vCSA):
Далее вам предложат, какие разделы нужно включить в сгенерированный бандл логов:
Если вы используете vCSA, то можно получить логи через веб-интерфейс. Для этого надо перейти по адресу:
https://<ip vcsa>/appliance/support-bundle
И далее ввести логин и пароль root от виртуального модуля vCSA.
После этого support bundle будет сгенерирован и загружен через ваш браузер.
Кроме этого, есть способ получить логи vCSA из Linux-системы с помощью утилиты curl. Для этого нужно выполнить следующую команду:
Здесь SearchTerm - это строка поиска, а LogName - это один из следующих логов:
hostd
vpxa
messages
vmkernel
vmksummary
vmkwarning
Получение Support Bundle для серверов ESXi
По аналогии с получением бандла для сервера VMware vCenter или vCSA, в vSphere Client можно выбрать сервер VMware ESXi и выбрать для него пункт "Export System Logs":
Также можно сгенерировать Support Bundle через тонкий клиент для управления серверами VMware ESXi - Embedded Host Client (он же - просто веб-интерфейс для управления хостами ESXi). Он доступен при соединении с хостом ESXi по ссылке:
https://<ip esxi>/ui
Для генерации саппорт бандла нужно выбрать пункт "Generate support bundle" из контекстного меню хоста:
Помимо этого, его можно сгенерировать и в консоли ESXi. Для этого используется команда vm-support без параметров (подробнее об этом написано в KB 1010705). Чтобы получить Support Bundle нужно в консоли ESXi выполнить следующую команду:
# vm-support
Надо отметить, что у утилиты есть множество разных параметров:
Аналогично получению бандла для vCenter, через PowerCLI можно получить и бандл для хоста ESXi. Соединяемся с хостом, забираем бандл и складываем его в нужную папку:
Многие из вас в производственной среде используют виртуальный модуль VMware vCenter Server Appliance (vCSA), представляющий собой готовую виртуальную машину с сервером управления виртуальной инфраструктурой.
Но не все знают, что есть простой способ обновить это средство (о нем мы упоминали вот тут). Для этого идем по адресу:
https://<IP-адрес vCSA>:5480
Где видим страницу логина в интерфейс Appliance Management:
Далее видим текущую версию vCSA в разделе Version и состояние сервера (Health Status):
В левой части выбираем раздел Update и далее пункт "Check Repository" (помните, что для этого на сервере vCSA должен быть интернет):
Далее вы увидите информацию о доступных обновлениях:
Далее выбираем пункт Install updates > Install all updates, чтобы запустить процесс обновления:
После этого сервер VMware vCSA будет обновлен, и можно будет его перезагрузить. Но у вас могут возникнуть проблемы с отображением health-статуса vCSA. Чтобы поправить это, нужно перезапустить все службы vCSA:
После обновления убедитесь, что номер версии обновился в консоли Appliance Management (выделено жирным - 6.5.0.14100). Также полезно будет убедиться, что обновился и номер билда (build number) в консоли vSphere Web Client:
Некоторые из вас знают, что VMware и другие производители в последнее время борются с уязвимостями Meltdown и Spectre в процессорах Intel, выпуская и отзывая патчи для различных компонентов ИТ-инфраструктуры. Мы писали об этом не так давно в следующих заметках:
Как вы знаете, из за патчей для данных уязвимостей на серверах ESXi иногда существенно проседает производительность (также подробно об этом написано тут), что необходимо отслеживать для того, чтобы не оказаться в ситуации неожиданного недостатка ресурсов в кластере после его апгрейда.
Напомним основные статьи VMware KB, касающиеся исправлений данных уязвимостей:
Еще в декабре 2017 некоторые из уязвимостей были пофикшены, но с тех пор у многих пользователей VMware vSphere появились проблемы с производительностью.
Один из сотрудников VMware опубликовал полезную заметку о том, как с помощью решения vRealize Operations Manager можно отслеживать производительность хостов ESXi в кластерах VMware HA/DRS и на основе этого принимать решения о патчинге тех или иных производственных сред и кластеров.
1. Трекинг версий BIOS и хостов ESXi для каждого сервера с использованием дэшборда Host Configuration.
Этот инструмент нужен, чтобы не забыть пропатчить хост-серверы ESXi:
2. Просмотр информации об использовании виртуальными машинами системных ресурсов.
Чтобы понять, как исторически изменилась производительность ВМ (CPU, Memory, IOPS и использование сети) после патчинга хостов ESXi, нужно смотреть именно на дэшборд VM utilization.
3. Также надо смотреть на изменения CPU и Memory Usage на уровне кластера с помощью дэшборда Capacity Overview.
4. С помощью дэшборда Heavy Hitters можно выяснить, какие из ВМ сейчас действительно сильно грузят оборудование.
5. Также если у вас есть 2 кластера, которые выполняют одну функцию в плане рабочих нагрузок - вы можете переместить нагрузки с помощью функции Workload Balance.
6. Возможность перераспределения емкости кластера можно узнать с помощью дэшборда Capacity Reclaimable.
7. Использование кастомных дэшбордов для Meltdown и Spectre.
Это возможно, если у вас издание vRealize Operations Advanced или более высокое, так как оно позволяет создавать кастомные дэшборды. Сотрудники VMware, Iwan Rahabok, Mark Scott и Luciano Gomes, разработали специальные дэшборды, которые сфокусированы на конфигурации, производительности, емкости и утилизации виртуальной инфраструктуры. Скачать все три дэшборда вместе с инструкциями можно по этой ссылке.
Эти следующие три дэшборда:
Performance Monitoring
Planning Guest OS Patching
Tracking vSphere Patching
7.1 Дэшборд Performance Monitoring.
Этот дэшборд позволяет отслеживать производительность CPU и памяти на всех уровнях - ВМ, хост, кластер. Соответственно, сравнивая исторические периоды, вы сможете сделать вывод о падении производительности.
7.2 Дэшборд Planning Guest OS Patching.
Этот дэшборд нужен для того, чтобы спланировать патчинг гостевых ОС. Сначала находятся все простаивающее ВМ, апдейт которых не сильно повлияет на функционирование виртуальной инфраструктуры, а в последнюю очередь идет обновление так называемых "heavy hitters" - рабочих лошадок вашего предприятия, апдейт которых должен проводиться с особой осторожностью.
7.3 Дэшборд Tracking vSphere Patching.
Этот дэшборд помогает планировать апгрейд различных версий VMware ESXi, а также версий виртуального аппаратного обеспечения (Virtual Hardware) виртуальных машин. Он решает 2 практические задачи:
Отслеживание номеров билдов VMware ESXi и прогресса патчинга серверов.
Отслеживание Virtual Hardware различных ВМ.
Совокупность всех этих инструментов позволит вам не только грамотно спланировать весь процесс патчинга гостевых ОС и хост-серверов, но и измерить влияние на производительность результата апгрейда хостов ESXi и прочих компонентов виртуальной инфраструктуры.
Как вы знаете, некоторое время назад были обнаружены серьезные уязвимости в процессорах компании Intel, условно называемые Meltdown и Spectre. Вскоре после их обнаружения многие производители выпустили обновления микрокода оборудования, многие из которых оказались неготовыми к эксплуатации в производственной среде (происходили неожиданные перезагрузки, падала производительность и появлялись другие эффекты).
Теперь, наконец, вышло обновление VMware vCenter Server Appliance 6.5 Update 1f, содержащее исправления для серверов управления на базе виртуального модуля с Photon OS на борту, исправляющее следующие дыры в безопасности:
Rogue data cache load issues (уязвимость Meltdown, CVE-2017-5754)
Надо отметить, что уязвимость Spectre-2 (Branch target injection - CVE-2017-5715) по-прежнему не исправлена в данном релизе.
Патч VMware vCenter 6.5 Update 1f можно загрузить с VMware Patch Portal (VMware-VCSA-all-6.5.0-7801515.iso):
В процессе апдейта будут обновлены следующие пакеты:
linux 4.4.110-2
libgcrypt 1.7.6-3
c-ares 1.12.0-2
ncurses 6.0-8
libtasn1 4.12-1
wget 1.18-3
procmail 3.22-4
rsync 3.1.2-4
apr 1.5.2-7
Также помимо VMware vCSA патч доступен и для решения vSphere Integrated Containers 1.3.1. На данный момент матрица выхода апдейтов фикса Meltdown и Spectre выглядит весьма удручающе (более подробно - вот тут):
Пропатчить VMware vCSA можно также через GUI из дефолтного репозитория обновлений продукта.
Ну и мы все еще ждем обновления для хостов VMware ESXi, которые до сих пор в статусе "Patch Pending".
Иногда у администраторов VMware vSphere появляется проблема на сервере VMware vCSA (виртуальный модуль vCenter), когда дисковое пространство в разделе /var/log забивается под завязку. Например, если выполнить команду ls, то получим вот такую картину:
vcsa-01:/var/log # ls -lh
total 4.6G
-rw-r----- 1 dnsmasq dnsmasq 17M Feb 4 08:32 dnsmasq.log
-rw-r----- 1 dnsmasq root 844M Jan 28 07:45 dnsmasq.log-20180128
-rw-r----- 1 dnsmasq dnsmasq 3.7G Feb 2 16:19 dnsmasq.log-20180204
Здесь мы видим целых 4,6 ГБ логов! Такая ситуация - не редкость, поэтому иногда нужно поменять настройки заполнения и ротации логов, чтобы раздел не забивался. В данном случае растет лог dnsmasq - кэша сервера DNS и DHCP на сервере vCSA (подробнее тут).
«Код безопасности» анонсировал выход продукта vGate 4.0. Решение для защиты виртуальных инфраструктур будет востребовано компаниями, применяющими виртуальные платформы VMware vSphere или Microsoft Hyper-V последних версий. Продукт позволяет настроить инфраструктуру согласно различным требованиям с помощью наборов политик, разграничить права доступа администраторов, а также обеспечить защиту от несанкционированного доступа к виртуализованным ресурсам.
А где же такие службы, как vmware-vpostgres, vpxd и прочие? Все просто - их запускает служба vmon. Это новый watchdog-сервис, который управляет службами vCSA в vSphere 6.5 и унифицирует доступ к ним через API.
Чтобы увидеть, в каком порядке она запускает прочие сервисы, выполним команды vmon-cli для остановки и запуска служб vmon на сервере vCSA:
/usr/lib/vmware-vmon/vmon-cli --batchstop ALL
/usr/lib/vmware-vmon/vmon-cli --batchstart ALL
Вывод будет примерно таким:
root@vc01 [ /var/log/vmware/vmon ]# grep "Executing op START on service" vmon-sys
17-12-12T09:44:23.639142+00:00 notice vmon Executing op START on service eam...
17-12-12T09:44:23.643113+00:00 notice vmon Executing op START on service cis-license...
17-12-12T09:44:23.643619+00:00 notice vmon Executing op START on service rhttpproxy...
17-12-12T09:44:23.644161+00:00 notice vmon Executing op START on service vmonapi...
17-12-12T09:44:23.644704+00:00 notice vmon Executing op START on service statsmonitor...
17-12-12T09:44:23.645413+00:00 notice vmon Executing op START on service applmgmt...
17-12-12T09:44:26.076456+00:00 notice vmon Executing op START on service sca...
17-12-12T09:44:26.139508+00:00 notice vmon Executing op START on service vsphere-client...
17-12-12T09:44:26.199049+00:00 notice vmon Executing op START on service cm...
17-12-12T09:44:26.199579+00:00 notice vmon Executing op START on service vsphere-ui...
17-12-12T09:44:26.200095+00:00 notice vmon Executing op START on service vmware-vpostgres...
17-12-12T09:45:33.427357+00:00 notice vmon Executing op START on service vpxd-svcs...
17-12-12T09:45:33.431203+00:00 notice vmon Executing op START on service vapi-endpoint...
17-12-12T09:46:54.874107+00:00 notice vmon Executing op START on service vpxd...
17-12-12T09:47:28.148275+00:00 notice vmon Executing op START on service sps...
17-12-12T09:47:28.169502+00:00 notice vmon Executing op START on service content-library...
17-12-12T09:47:28.176130+00:00 notice vmon Executing op START on service vsm...
17-12-12T09:47:28.195833+00:00 notice vmon Executing op START on service updatemgr...
17-12-12T09:47:28.206981+00:00 notice vmon Executing op START on service pschealth...
17-12-12T09:47:28.220975+00:00 notice vmon Executing op START on service vsan-health...
Как мы видим, службы запускаются в следующем порядке:
А вы знали, что резервные копии vCSA имеют срок годности? Вот и я тоже нет. Скажу вам больше, не все инженеры технической поддержки VMware GSS знают об этом! На самом деле то, что имеет срок годности — это пароль учётной записи root внутри OVF template на инсталляционном диске vCSA ISO! Я тоже был удивлён, но VMware называет это известной проблемой “known issue” в своей KB51124.
Там мы рассказывали, что vCHA - это Active/Passive кластер, который состоит из трех компонентов - активного узла, работающего под нагрузкой, пассивного, готового взять на себя нагрузку в случае сбоя активного, а также компонента Witness ("свидетель") - который защищает кластер от ситуации split-brain (оба узла считают себя активными в случае изоляции сети) и является кворумным узлом:
Напомним, что кворумный узел не может получить роль сервера vCenter, это лишь маленькая машина, реализующую функцию Witness в ситуациях изоляции и разделения сети.
Если посмотреть на архитектуру решения, то можно понять, что оно не использует сеть хранения для сигналов доступности и не рассчитано на множественные сбои, что позволит гарантированно сохранить или восстановить работоспособность только в случае отказа/изоляции лишь одного из компонентов. Если, например, вся сеть развалится между всеми тремя узлами - vCHA вас не спасет.
С точки зрения синхронизации, кластер vCHA использует синхронную репликацию PostgreSQL native replication для синхронизации базы данных (в случае отказа БД будет консистентная) и утилиту rsync для репликации файлов vCenter (например, файлов конфигурации):
Поэтому надо понимать, что теоретически некоторые файлы при сбое можно будет потерять, так как репликация асинхронная (но это, в целом, маловероятно).
Оба узла vCSA в кластере vCHA используют один публичный IP-адрес, который используется при доступе и к резервному узлу в случае сбоя основного. В условия восстановления работоспособности сервера vCSA заложен показатель RTO=5 минут. Это значит, что в случае сбоя основного узла, где-то 5 минут пользователи могут испытывать проблемы с доступностью vCenter через vSphere Client или vSphere Web Client. При этом API vCenter будет доступен уже где-то через 2-3 минуты.
Теперь давайте посмотрим, как обрабатываются механизмом vCHA различные варианты отказов:
Отказ активного узла. В этом случае пассивный узел видит, что активный узел больше недоступен, при этом узел Witness работает и доступен. Пассивный узел назначает себя активным и начинает обслуживать запросы клиентов vSphere.
Отказ пассивного узла. Поскольку активный узел и Witness чувствуют себя нормально, сервер vCenter продолжит обслуживание клиентов.
Отказ узла Witness. В этом случае сохранится статус кво - активный узел продолжит обрабатывать запросы, а пассивный будет готов взять на себя нагрузку в случае сбоя активного.
Изоляция или отказ более чем одного узла. В этом случае вполне может возникнуть ситуация, когда у вас сервисы vCenter не функционируют - например, оба узла vCSA могут посчитать себя изолированными (см. далее).
Поведение изолированного узла vCSA при изоляции
Как только узел себя считает изолированным, он сразу гасит все сервисы vCenter, чтобы второй узел мог взять на себя нагрузку по обслуживанию запросов (при этом неважно, видит ли второй узел компонент Witness). При детектировании события изоляции учитываются возможные короткие промежутки в доступности сети, которые могут иногда возникать при нормальном сетевом взаимодействии. Только когда все попытки достучаться до второго узла и Witness исчерпаны, узел vCSA считает себя изолированным.
Мы часто пишем о виртуальном модуле VMware vCenter Server Appliance (vCSA), который представляет собой готовую виртуальную машину для управления виртуальной инфраструктурой VMware vSphere (напомним, что это полноценная замена vCenter for Windows).
Сегодня мы покажем несколько интересных утилит командной строки vCSA, которые могут помочь вам в ежедневной эксплуатации этого управляющего сервиса.
1. Просмотр журнала Cron.
vCSA имел раньше проблемы со сжатием фалов журнала (логов), что приводило к тому, что дисковые разделы быстро заполнялись. Поэтому следующей командой можно посмотреть, когда в последний раз выполнялись запланированные задачи Cron:
ls -l /var/spool/cron/lastrun/
Для сравнения ниже приведен вывод этой команды совместно с выводом текущей даты:
vc:~ # date
Mon Dec 4 12:55:39 CET 2017
vc:~ # ls -l /var/spool/cron/lastrun/
total 0
-rw------- 1 root root 0 Dec 3 20:00 cron.daily
-rw------- 1 root root 0 Dec 4 12:15 cron.hourly
-rw------- 1 root root 0 Dec 1 20:00 cron.weekly
Как мы видим, крон успешно выполнялся для ежечасной задачи, ежедневной и еженедельной. Если же крон отвалился, то значит, скорее всего, устарел пароль root. Узнать это можно следующей командой:
grep "Authentication token is no longer valid; new one required" /var/log/messages.0.log | head
Если в выводе этой команды будет что-то вроде этого:
<timestamp> vcenter /usr/sbin/cron[<ID>]: Authentication token is no longer valid; new one required
значит пароль root устарел.
2. Смена устаревшего пароля root.
Если ваш пароль root устарел, и крон-таски vCSA не запускаются, то сменить его проще всего будет следующей командой (обратите внимание, что это НЕ слово change):
chage -l root
У вас запросят старый пароль и попросят задать новый:
Password change requested. Choose a new password.
Old Password:
New password:
После этого можно снова вывести срок действия пароля с помощью chage (тут видно, что он устареет через 99999 дней, то есть 274 года):
vc:~ # chage -l root
Minimum: 0
Maximum: 99999
Warning: 7
Inactive: -1
Last Change: Dec 27, 2016
Password Expires: Never
Password Inactive: Never
Account Expires: Never
3. Перезапуск служб vCSA.
Если вы хотите поправить странное поведение vCSA, которое может быть связано с некорректным поведением сервисов Linux внутри виртуального модуля, то можно перезапустить все службы:
Можно перезапустить, например, только vSphere Client:
service-control --stop vsphere-client
Список запущенных служб узнается так:
service-control --list
А вот так узнается статус того или иного сервиса:
service-control --status
4. Работа с LVM
Если вам надо увеличить виртуальные диски VMDK, а потом расширить тома LVM, то можете прочитать вот эту нашу статью. Чтобы не использовать API Explorer или PowerCLI, можно выполнить следующую команду для просмотра томов LVM:
Для идентификации дисковых устройств и их типов можно выполнить следующее:
lsscsi
Вывод будет примерно таков:
vc:~ # lsscsi
[0:0:0:0] disk VMware Virtual disk 1.0 /dev/sda
[0:0:1:0] disk VMware Virtual disk 1.0 /dev/sdb
[0:0:2:0] disk VMware Virtual disk 1.0 /dev/sdc
[0:0:3:0] disk VMware Virtual disk 1.0 /dev/sdd
[0:0:4:0] disk VMware Virtual disk 1.0 /dev/sde
[0:0:5:0] disk VMware Virtual disk 1.0 /dev/sdf
[0:0:6:0] disk VMware Virtual disk 1.0 /dev/sdg
[0:0:8:0] disk VMware Virtual disk 1.0 /dev/sdh
[0:0:10:0] disk VMware Virtual disk 1.0 /dev/sdi
[0:0:12:0] disk VMware Virtual disk 1.0 /dev/sdj
[0:0:14:0] disk VMware Virtual disk 1.0 /dev/sdk
[1:0:0:0] cd/dvd NECVMWar VMware IDE CDR00 1.00 /dev/sr0
Когда вы поймете, какой том нужно увеличить, выполните команду:
vpxd_servicecfg storage lvm autogrow
Надо помнить, что это сработает только для томов под управлением LVM (например, для disk 1 (sda) с разделом / - не сработает).
5. Поиск "загрязняющих" файлов.
Чтобы найти логи, которые могут засорить корневой раздел или раздел /storage/log, выполните одну из следующих команд:
du -a /var | sort -n -r | head -n 10
du -a /storage/log | sort -n -r | head -n 10
6. Изменение режима ротации логов (Log Rotation).
Сначала перейдем в папку с логами:
cd /etc/logrotate.d
Далее сделаем бэкап настроек:
cp dnsmasq ./dnsmasq.old
Затем откроем настройки:
vi dnsmasq
И поменяем слово "weekly" (еженедельно) на "daily" (ежедневно), например:
После этого можно удалить старый большой лог следующими командами:
cd /var/log
rm dnsmasq.log
7. Удаление файлов, которые не удалились.
Бывает так, что вы удалили большой файл, а дисковое пространство не высвободилось - и это видно командой df -h. Это происходит потому, что какой-то из процессов в памяти еще держит файл (при этом не обязательно использует его). Чтобы узнать, что это за процесс выполняем команду:
RSS
